개요

OpenTelemetry 는 분산된 시스템의 모니터링과 추적을 위한 표준화된 도구입니다.
스마일게이트의 하이브리드 클라우드 Kubernetes 환경에서 OpenTelemetry 를 사용하여 Observability 를 고도화한 사례를 소개합니다.
기존 사용하던 Observability 의 한계점을 소개하고, OpenTelemetry 와 Grafana LGTM (Log, Metrics, Tracing)를 활용하여 다수의 서비스 클러스터를 관측하기 위해 하나의 Observability 클러스터를 구성한 을 경험을 소개합니다.
이를 통해 스마일게이트 플랫폼 서비스의 서비스 가시성을 높일 수 있던 경험과 구축 과정에서의 트러블 슈팅 및 해결 방법을 공유하며 Cloud Native 하게 Observability 를 고도화한 사례에 대해 발표할 예정입니다.

발표

관측가능성이란?

모니터링과 비슷하지만 조금 다르다.
시스템의 상태를 지속적으로 감시하고, metric과 trace까지 합하여 예상치 못한 문제도 분석
사전, 사후 대응도 포함된 개념

크게 3 개념
log, metric, trace

기존 관측가능성 운영 환경

기존에도 lgtm 스택 활용
promtail로 로그 모으고 loki가 수집
프메로 메트릭 가져옴
pinpoint 활용하여 트레이싱
모든 시각화는 그라파나

여러 클러스터에서는 그라파나는 하나로 관리

그러나 부족한 부분

• 모니터링 도구 통합의 필요성
  • 각 개념에 일관된 view가 없음
• 언어 종속성 벗어난 도구 필요성
  • pinpoint는 자바 기반의 분산 추적.
  • 자바에 대해서만 대응 가능
  • 데이터독과 같은 상용 모니터링 도구와도 연동이 돼야 할 필요 가있었음
• 리소스 비용 최적화 필요
  • 카산드라와 hbase는 운영 복잡성과 비용을 증가시킴
  • 타노스의 다운샘플링을 통하 비용절감이 좋긴 했으나, 원본과 샘플링이 동시에 존재하는 순간 오히려 비용 증가
  • 쿼리 속도 저하까지 문제 있었음

opentelemetry, lgtm 을 통한 cloud native 환경 구축

그래서 도입!

opentelemetry

별다줄 오텔
단일 툴로 통일된 형태로 지표 수집
통일된 프로토콜을 사용하도록 지정

• 표준화
  • 일관되어 종속성 탈피
• 확장성
  • 분산 아키텍쳐에서 활용 가능
  • 필요에 따라 각 지표를 따로
  • 수평 확장 용이한 구조
• 다양한 언어
• 오픈소스
• 커뮤니티

구성요소

• otel spec
  • 수집할 데이터와 통신 방식, sdk 등를 정의한느 명세서
• otel collector
  • 수집, 처리하는 중간 처리기
  • 필수는 아니고 어댑터처럼 사용하는 듯?
  • 세가지 컴포넌트로 돼있고 하나의 파이프라인 구성
    • 리시버
      • 프로세서로 데이터 보냄
    • 프로세서
      • 필요한 속성 수집 및 변환
    • 익스포터
      • 데이터 백엔드로 보냄
    • 1:N 관계로 설정할 수 있음
  • 컬렉터 패턴
    • 컬렉터를 안 쓰는 것도 가능
    • agent mode
      • 데몬셋이나, 사이드카 형식으로 구성
      • 특정 컬렉터에 집중되지 않음
    • gateway mode
      • 소수 컬렉터가 처리
      • 디플 형식
    • 이 두가지를 혼합하여 사용하는 경우는 멀티 클러스터를 사용할 때
• otel instrumentation
  • 앱에 설치해 수동, 자동으로 모으는 계측기
  • sdk로 개발자가 직접 할수 도 있고, agent 활용도 가능
  • 자동 agent방식
    • otel 오퍼레이터 활용해서 자동화 가능
      • 자바 파드에 어노테이션 넣기
      • otel crd에 각종 설정을 미리 정할 수 있음
    • 각 설정은 init 컨테이너로 들어가서 미리 설정됨
    • 이후 컬렉터가 백엔드로 보냄
  • sdk
    • 고 언어에 대해 지원 안해 서 직접 만들어야 함

사내 적용

로그

otlp에서 컬렉터로 전송
컬렉터

• 리시버
  • 어떤 프로토콜로 수집할지
• 프로세서
  • 배치, 메모리 제한 등의 다양한 설정
• 익스포터
  • 로키 주소 명시
    이것을 로키가 저장
    워커 노드의 로컬 파일

메트릭

기존에는 타노스로 오래 저장
이것도 컬렉터 사용
이번엔 mimir 사용
데이터 압축, 저장 잘해오

이때 istio 관련은 커스텀 메트릭이 너무 많아서 alloy라는 컴포넌트를 넣음
alloy도 다운샘플링 지원. 타노스 쌉 상위호환
프메를 대체서 메트릭 수집. 일부를 필터링하며 클러스터 모드로 구성됨
ha 가능
로그 스트림 방식이라 클러스터 레벨 로그 수집 가능

트레이스

이번에는 템포 사용
다 컬렉터를 거치는 과정을 둠
템포는 오브젝트 스토리지를 사용해서 간편하고 장기 보관 적합하다

멀티 클러스터 적용

관측용 클러스터 따로 구축
컬렉터 부분까지 떼어내서 따로 구성

장점

하나의 대시보드에서 관리 가능
아까 말한 것들 해결됨

QnA

• 이전과 비교해서 어려운 점
  • 각 항목 별 키값이나 이런 게 다르다.
  • 동일한 값인데도 서비스 별로 다르게 적용하는 게 어려움
• 서비스 메시에 대한 alloy로 어떤 최적화가 되엇는가?
  • 이스티오 관련커스텀 메트릭이 너무 많았다.
  • 필요한 것만 정의하고 파드를 배포.
  • 이걸 alloy로 수집
• 사이드카로 사용하면 일단 뭔가 너무 많지 않나
  • 우린 그런 거 ㅇㅄ다
• 어떻게 언어 자유로운 agent가 되냐? jvm 건드리냐
  • 그렇다(ㄹㅇ..?)

참고